docs: record stable 0.1.1 release

AGENTS.md

@@ -51,14 +51,14 @@ repository.
   merely to complete lifecycle cleanup. Fail closed and report the exact state
   whenever a required cleanliness, fetch, or fast-forward condition is not met.
 
-## Current Milestone: Stable 0.1.0 Complete
+## Current Milestone: Stable 0.1.1 and Repository Foundation Complete
 
-Private Remote Validation, Public Preview, Registry Alpha, and stable `0.1.0`
-are complete. The canonical repository is public, `0.1.0` is available from
-npm's `latest` channel, and `0.1.0-alpha.3` remains available from `next`; both
-published lines have OIDC provenance and verified public-install evidence. No
-later milestone is active. Do not begin the 0.2 provider adapters without an
-explicit maintainer request.
+Private Remote Validation, Public Preview, Registry Alpha, stable `0.1.0`, and
+the `0.1.1` maintenance patch are complete. The canonical repository is public,
+`0.1.1` is available from npm's `latest` channel, and `0.1.0-alpha.3` remains
+available from `next`; the published lines have verified provenance and
+public-install evidence. No later milestone is active. Do not begin the 0.2
+provider adapters without an explicit maintainer request.
 
 The accepted identity is:
 
@@ -78,25 +78,21 @@ The unscoped `cometapi` package is the primary Node SDK. `@cometapi` is the
 standard scope for future official scoped packages; do not introduce new
 official packages under `@cometapi-dev`.
 
-Stable promotion used Release Please only for its reviewed version and
-changelog pull request. Because the pinned Release Please v5 path is vulnerable
-to an upstream single-package tagging defect, it skipped GitHub release
-creation. A maintainer created and reviewed the immutable `v0.1.0` release
-manually against the exact merged release commit, and the publish workflow
-completed exact-artifact verification, the bounded live smoke, npm OIDC
-publication, and registry verification.
-
-Release Please remains disabled between release operations after its post-0.1.0
-run generated an unreviewed `0.2.0` temporary-branch commit and then failed to
-create a pull request. That branch was verified as failure-only evidence before
-the authorized 0.1.1 operation replaced it with the action-owned patch branch.
-Do not use either branch as a 0.2 starting point. The 0.1.1 maintenance task
-repairs the workflow around the current read-only-default Actions baseline with
-action-created pull requests enabled; any later enablement still requires an
-explicit maintainer request and the fail-closed checks in `RELEASING.md`.
-For this repair, merge the anchor-removal finalization PR first, then use a new
-first-attempt manual dispatch to refresh the same action-owned 0.1.1 PR before
-its final CI and human-owner review.
+Stable `0.1.1` corrected the public options boundary without expanding the 0.1
+resource surface. Release Please created the reviewed patch PR, immutable tag,
+and GitHub Release. Publication required a disclosed one-time main-context
+recovery because the immutable tag predated the repaired tag handoff. The
+recovery published only the exact previously verified artifact through npm
+OIDC, then the repository restored its variables and tag-only Environment
+policy. The current workflow contains no publication-recovery input, fixed
+recovery run or artifact ID, prior-package-artifact or live-evidence reuse, or
+branch-context publication path.
+
+Release Please remains disabled between explicitly authorized release
+operations. Permanent stable patches follow only the tag-bound path in
+`RELEASING.md`. The `0.1.1` recovery provenance is historical evidence, not
+proof that the current permanent tag path has completed a registry publication;
+the next explicitly authorized stable patch is its first end-to-end execution.
 
 ## Product Contract
 
@@ -256,6 +252,32 @@ repository root.
 - The legal copyright holder and official security and support contacts must be
   maintainer-confirmed and must never be invented.
 
+### Stable patch workflow
+
+- Follow the stable-patch route in `RELEASING.md`: Release Please prepares the
+  reviewed patch PR and immutable Release, an unprivileged handoff dispatches
+  `publish.yml` from the exact immutable tag, and only that tag-bound run may
+  verify, run the bounded live smoke, enter the npm Environment, or request OIDC.
+- Before requesting review, compare the PR author login with the intended
+  reviewer login. A PR author cannot approve the same PR even when that author
+  is a repository administrator.
+- Under a zero-required-approval ruleset, a same-author exact-head `COMMENTED`
+  review is an owner audit only and must never be described as `APPROVED`. Any
+  required approval must be a formal exact-head `APPROVED` review from a
+  different human. An action-authored Release Please PR always requires that
+  distinct-human administrator approval.
+- GitHub's **Approve and run workflows** control authorizes a workflow run for
+  CI; it is separate from the PR review gate and satisfies no review requirement.
+- Prepare or refresh a release PR with a new first-attempt manual Release Please
+  dispatch. Do not rerun a preparation dispatch. Release Please same-run Release
+  reconciliation is allowed only under the exact conditions in `RELEASING.md`.
+- Never bypass a failed stable release with a manual or auxiliary tag, a
+  branch-context publish, a temporary `main` npm Environment policy, reused
+  artifact or live evidence, an arbitrary rerun, or a different patch version.
+- After registry verification, immediately restore
+  `RELEASE_PLEASE_ENABLED=false`, keep `LIVE_SMOKE_ENABLED=true`, and require the
+  npm Environment deployment-policy set to contain only `tag:v*`.
+
 Before Public Preview, run `npm run check:public-preview`. The gate must fail
 after reporting all violations until canonical identity, contacts, repository
 metadata, and durable public-facing content are complete.

ARCHITECTURE.md

@@ -108,9 +108,10 @@ tag and GitHub release agreement.
 The publish workflow is the sole source of npm dist-tag selection: prereleases
 use `next`, stable versions use `latest`. The package manifest must not carry a
 static dist-tag because that would make stable and prerelease policy diverge.
-Trusted Publishing remains the default authentication path. The only token
-path is an explicitly enabled protected-environment fallback that rejects every
-version except `0.1.0-alpha.1` and every dist-tag except `next`.
+Trusted Publishing is the only executable authentication path. The protected-
+environment token bootstrap used for `0.1.0-alpha.1` is historical evidence;
+current workflows contain no token publication path and reject registry-token
+credentials.
 
 For normal stable patches, Release Please owns the reviewed version/changelog
 PR and the immutable tag and GitHub Release. The configuration uses an explicit
@@ -119,20 +120,23 @@ maintenance window cannot enter 0.2 implicitly and a root package does not fall
 into the single-package tag-discovery ambiguity encountered during 0.1.0. The
 workflow also rejects commit-level `Release-As:` notes before mutation because
 Release Please applies those overrides before its patch versioning strategy.
-Because a
-GitHub Release created with the default `GITHUB_TOKEN` does not start a separate
-`release.published` workflow, publication is chained from the successful
-Release Please workflow. The handoff accepts only the canonical repository's
-successful attempt-qualified `push` run for `main` at the still-current exact
-`main` SHA. The release workflow records normalized action outcome, recovery
-state, pre-action Release presence, the exact Release-producing attempt, SHA,
-tag, version, URL, repository, workflow identity, run ID, and attempt in a
-schema-v2 exact-run artifact. Publication
-downloads and validates only that attempt's artifact before checking the tag and
-immutable Release. A first-attempt manual run is explicitly release-inert and
-must succeed only after independently validating one canonical action-created
-patch PR; its event cannot enter publication. Any successful `push` run without
-the exact result artifact, tag, and immutable Release fails before live or
+Because a GitHub Release created with the default `GITHUB_TOKEN` does not start
+a separate `release.published` workflow, publication is chained from the
+successful Release Please workflow. The handoff accepts only the canonical
+repository's successful attempt-qualified `push` run for `main` at the
+still-current exact `main` SHA. The release workflow records normalized action
+outcome, same-run Release reconciliation state, pre-action Release presence,
+the exact Release-producing attempt, SHA, tag, version, URL, repository,
+workflow identity, run ID, and attempt in a schema-v2 exact-run artifact. An
+unprivileged `workflow_run` handoff validates only that attempt's artifact,
+exact tag, immutable Release, and current `main`, then dispatches `publish.yml`
+with `ref=v<version>`. Only that tag-bound `workflow_dispatch` can reach fresh
+artifact verification, bounded live smoke, the npm Environment, or OIDC. A
+first-attempt manual run is explicitly release-inert and must succeed only after
+independently validating one canonical action-created patch PR; its event cannot
+enter publication. A successful `push` preparation run whose result-upload step
+was skipped is also release-inert. Any purported release handoff with missing or
+mismatched result, tag, or immutable Release evidence fails before live or
 registry access. The release outcome and package artifact are verified
 independently.
 
@@ -143,17 +147,19 @@ fail-closed on exact tag, artifact, dist-tag, integrity, and provenance state.
 Manual preparation rejects attempt 2 or later; restart uses a new dispatch with
 Release creation disabled. A `push` rerun is bounded to the same run ID, SHA,
 candidate, and final-head review. It may retry while the tag and Release remain
-absent. If an earlier attempt already created the Release, recovery accepts only
-the exact bot-authored immutable Release at that SHA whose publication time
-falls inside exactly one earlier Release Please step from the same run.
+absent. If an earlier attempt already created the Release, same-run
+reconciliation accepts only the exact bot-authored immutable Release at that
+SHA whose publication time falls inside exactly one earlier Release Please step
+from that run.
 Release-mode action failure is tolerated only long enough to
 prove that postcondition, reconcile the release PR to `autorelease: tagged`, and
 write the attempt-qualified artifact. The authorized Actions setting lets the
 default token create the PR; the resulting approval-required CI still needs a
 human with write access to authorize execution, and bot review cannot satisfy
-the release gate. A merged
-release PR is accepted for tagging only after a distinct repository
-administrator approved its final head. The workflow checks the triggering SHA,
+the release gate. A head change invalidates both a prior `COMMENTED` owner audit
+and a formal approval. A merged release PR is accepted for tagging only after a
+distinct human repository administrator formally approved its exact final
+head. The workflow checks the triggering SHA,
 release-branch snapshot, all open and closed PR identities, current review, and
 tag/Release state immediately before Release Please mutation, then rechecks
 `main`, the release branch, the complete PR snapshot, exact final-head approval,
@@ -164,6 +170,17 @@ additional PR cannot be tagged. Manual dispatch is therefore release-inert: it
 may prepare one canonical action-created PR only when no merged release PR is
 awaiting a tag.
 
+Stable `0.1.1` used a one-time main-context publication recovery after its
+immutable tag predated the permanent tag-bound workflow. It reused only the
+previously verified exact artifact and bounded live evidence, so npm provenance
+names the reviewed recovery control commit on `refs/heads/main` rather than the
+tag. [PR #41](https://github.com/cometapi-dev/cometapi-node/pull/41) removed
+every fixed recovery identifier, prior-evidence reuse branch, and temporary
+`main` deployment-policy path. The permanent npm Environment policy set is
+exactly `tag:v*`; branch-context publication is not part of the architecture.
+The exception is historical evidence and must never be reconstructed. See
+[Stable 0.1.1 release evidence](./RELEASING.md#stable-011-release-evidence).
+
 ## Testing layers
 
 Evidence is separated by layer:

COMPATIBILITY.md

@@ -3,11 +3,9 @@
 Compatibility document version: 0.1  
 Package line: `0.1.x`
 
-Stable release: `0.1.0`; the immutable release workflow and separate
-post-publication registry verification completed on 2026-07-28.
-
-Maintenance candidate: `0.1.1`; the options-contract and Release Please repair
-is not a release claim until its remote release and registry evidence completes.
+Stable release: `0.1.1`; the immutable Release, bounded live smoke, npm OIDC
+publication, and separate public-registry verification completed on 2026-07-30.
+Registry Alpha `0.1.0-alpha.3` remains available from npm's `next` channel.
 
 This matrix defines the contract-tested 0.1 compatibility surface. Inheritance
 from the official OpenAI client does not by itself establish CometAPI support.
@@ -136,3 +134,15 @@ signatures and provenance, and public artifact checks passed in
 A separate post-publication registry-tarball check also passed the ESM,
 CommonJS, and compatible-OpenAI host fixtures with one effective
 `openai@6.47.0` installation and preserved official error identities.
+
+For stable `0.1.1`, the final release-PR head passed the blocking, minimum,
+locked, latest-compatible, Node.js 26 advisory, package, workflow, and
+standalone lanes in
+[CI run 30468358086](https://github.com/cometapi-dev/cometapi-node/actions/runs/30468358086).
+Release Please created the immutable
+[`v0.1.1` Release](https://github.com/cometapi-dev/cometapi-node/releases/tag/v0.1.1),
+and the bounded live smoke plus OIDC publication completed in the evidence
+chain recorded in [RELEASING.md](./RELEASING.md#stable-011-release-evidence).
+Separate public-registry verification passed ESM, CommonJS, declarations,
+supported mocked calls, one effective OpenAI installation, official error
+identity, integrity, signature, and provenance.

README.md

@@ -4,15 +4,12 @@ The official CometAPI entry point for the OpenAI-compatible API. The SDK keeps
 the official OpenAI JavaScript request, response, stream, and error types while
 defaulting the client to CometAPI.
 
-> **Stable 0.1 release:** `0.1.0` is approved for npm publication. Publication
-> is complete, and the package is available from npm's default `latest` dist-tag.
-> The supported API is limited to the contract-tested 0.1 surface documented
-> here and in [COMPATIBILITY.md](./COMPATIBILITY.md).
->
-> **Approved maintenance candidate:** `0.1.1` is approved for npm publication
-> through the reviewed Release Please path. This approval is not a release
-> claim: `0.1.1` remains unpublished until the immutable release, npm OIDC
-> publication, and public-registry verification complete.
+> **Stable 0.1 release:** `0.1.1` is published on npm's default `latest`
+> dist-tag. Its immutable GitHub Release, bounded live smoke, npm OIDC
+> publication, provenance, signature, and separate public-registry installation
+> verification are complete. The supported API remains limited to the
+> contract-tested 0.1 surface documented here and in
+> [COMPATIBILITY.md](./COMPATIBILITY.md).
 
 ## Supported 0.1 surface
 
@@ -232,23 +229,24 @@ parent.
 
 ## Project status
 
-The repository has completed Public Preview, Registry Alpha, and stable 0.1.0.
-Blocking CI, protected repository rules, security reporting, protected
-environments, and the authorized release-tag live smoke have passed. Stable
-`0.1.0` was published from its immutable release artifact through GitHub
-Actions OIDC with provenance, and a separate post-publication check passed the
-ESM, CommonJS, and compatible-OpenAI host fixtures against the registry tarball.
-Registry Alpha `0.1.0-alpha.3` remains available from `next`. The immutable
-`0.1.0-alpha.2` GitHub release remains as an unpublished failure record because
-its guard stopped before invoking npm. Mocked responses, packed artifacts,
-GitHub Actions, trusted live tests, and npm publication remain separate evidence
-layers and must not be represented as another. Because published npm artifacts
-are immutable, the `0.1.0` tarball retains its candidate-era README; this
-post-release status update first ships in a later package version.
-
-The `0.1.1` options-contract and Release Please repair is in progress. Until its
-full release sequence completes, npm `latest` remains `0.1.0` and this candidate
-must not be described as published. No 0.2 provider adapter work is included.
+The repository has completed Public Preview, Registry Alpha, stable `0.1.0`,
+the `0.1.1` maintenance patch, and Repository foundation. Blocking CI,
+protected repository rules, security reporting, protected environments, and
+the authorized bounded live smoke have passed. Stable `0.1.1` is available from
+`latest`; Registry Alpha `0.1.0-alpha.3` remains available from `next`. A
+separate public-registry check passed ESM, CommonJS, declarations, supported
+mocked calls, the compatible-OpenAI host fixture with one effective OpenAI
+installation, official error identity, integrity, signature, and provenance.
+
+The immutable `0.1.0-alpha.2` GitHub release remains as an unpublished failure
+record because its guard stopped before invoking npm. Mocked responses, packed
+artifacts, GitHub Actions, trusted live tests, and npm publication remain
+separate evidence layers and must not be represented as another. Published npm
+artifacts are immutable, so the `0.1.1` tarball retains its candidate-era
+README; this post-release status first ships in a later package version. The
+one-time `0.1.1` publication recovery is documented as historical evidence in
+[RELEASING.md](./RELEASING.md); the current permanent release workflow is
+immutable-tag-bound. No 0.2 provider adapter work is included.
 
 See: