Normalize npm, tag, and GitHub release authority

[Jesssullivan]

Current public release surfaces are not aligned.

Observed on 2026-04-25:

• npm latest: @tummycrypt/scheduling-kit@0.7.2
• package.json: 0.7.2
• MODULE.bazel: 0.7.2
• BUILD.bazel package target: 0.7.2
• latest GitHub release shown by gh release list: v0.6.1
• latest Git tag returned by GitHub API: v0.7.0

Why it matters:

• Downstream consumers such as MassageIthaca correctly consume the npm package, but release auditors cannot reconstruct package authority from GitHub releases/tags alone.
• The publish workflow is release-event driven, so release/tag hygiene should be part of package authority rather than an afterthought.

Acceptance:

• Decide whether every npm-published version should have a matching signed/annotated tag and GitHub release.
• Backfill or explicitly document the missing v0.7.1 / v0.7.2 release surfaces.
• Add a release checklist or workflow guard so future npm latest, package.json, Bazel metadata, tags, and GitHub Releases cannot silently diverge.
• Keep the package public-surface wording business-agnostic and avoid app-specific deployment claims.

Refs: TIN-89 package/Bazel/CI/publish truth.

[Jesssullivan]

Opened #74 to align AGENTS.md with the current package-authority state.

Relevant docs changes:

• current main metadata is @tummycrypt/scheduling-kit@0.7.2
• release/tag/npm/GitHub release drift remains tracked here
• CI/publish now uses js-bazel-package with publishable output from ./bazel-bin/pkg
• runner lane should not be treated as stable until repo runner visibility and green workflow runs prove it

No runtime or package metadata changes.

[Jesssullivan]

Opened #78 as a release-authority guard follow-up. It does not backfill old GitHub releases/tags, but it adds a repeatable metadata/workflow check so package metadata, Bazel package metadata, and the publishable artifact path cannot silently drift again.

[Jesssullivan]

Refreshed release-authority truth on 2026-04-27:

• npm latest is still @tummycrypt/scheduling-kit@0.7.2.
• GitHub Releases still stop at v0.6.1.
• Git tags include v0.7.0, but not v0.7.1 or v0.7.2.

Updated draft PR #82 to cover the repeatable checklist portion of this issue alongside the devshell/cache/provenance work: #82

The historical backfill/documentation decision for v0.7.1 / v0.7.2 remains open; the PR makes that gap explicit instead of treating the latest GitHub Release as complete package truth.

[Jesssullivan]

2026-04-28 update after package/Bazel merge train:\n\n- Merged #83 (package-scoped Bazel npm repo) as a6f9f52.\n- Merged #85 (Bazel module edges + tinyland registry config) as 49454d1.\n- Current main metadata now reports package.json/MODULE.bazel version 0.7.3.\n- npm latest is also @tummycrypt/scheduling-kit@0.7.3.\n- Git tags still only include v0.7.0; there is no v0.7.2/v0.7.3 tag.\n- tinyland-inc/bazel-registry still only registers tummycrypt_scheduling_kit/0.7.0.\n- npm tarball 0.7.3 does not include MODULE.bazel/BUILD.bazel, so it is not a suitable Bazel registry source. Registry needs a Git source archive/tag or an explicit decision to change package contents.\n\nCurrent blocker: backfill/tag/register 0.7.3 (or explicitly document why registry remains at 0.7.0) before downstream modules can depend on latest scheduling-kit via Bazel truth.

[Jesssullivan]

Opened draft #86 for the clean follow-up release version: bump to 0.7.4 from current post-#83/#85 main.\n\nReason: npm 0.7.3 was published from 67f6eb before the Bazel scoped-npm/module-edge work, so retro-tagging current main as v0.7.3 would be inaccurate. 0.7.4 gives us a truthful source archive target for a tag, GitHub Release, and bazel-registry entry once current main CI is green.\n\nLocal validation for #86: pnpm check:release-metadata and git diff --check.

[Jesssullivan]

#86 merged as 1aa7604 and main CI run 25082296588 is green on Node 20 and 22, including release metadata, package surface, Bazel targets, npm tarball validation, npm publish dry-run, and GitHub Packages dry-run.\n\nCurrent state is intentionally:\n- repo main/package metadata: 0.7.4\n- npm latest: 0.7.3\n- Git tags: still no v0.7.4\n- bazel-registry: still only tummycrypt_scheduling_kit/0.7.0\n\nNext step requires an explicit release operation: publish/tag v0.7.4, then add the tinyland-inc/bazel-registry module entry for tummycrypt_scheduling_kit/0.7.4, then update bridge #90 off the temporary 0.7.0 registry pin.

[Jesssullivan]

Release authority update: v0.7.4 is now published and verified. GitHub release/tag v0.7.4 points at 1aa7604; release workflow 25082744736 completed successfully across Node 20/22 validation, npm publish, and GitHub Packages publish. npm now reports @tummycrypt/scheduling-kit@0.7.4 as latest. Bazel registry entry tummycrypt_scheduling_kit@0.7.4 was registered via tinyland-inc/bazel-registry#24 and merged at aa7681460944e2e84aee83e72fb8b8138350468c.

[Jesssullivan]

2026-05-02 update: current npm/GitHub release/registry truth is now at kit 0.7.5, but downstream Bzlmod package consumption exposed a remaining release-authority gap. A temp consumer could resolve the registry graph, but bazel build @tummycrypt_scheduling_kit//:pkg failed from the external module because the Svelte package action assumed a main-workspace-relative src path and then hit read-only .svelte-kit state in the sandbox.

Opened draft PR #89 for the truthful fix/release-candidate lane: bump to 0.7.6, package from a declared Bazel source tree through a writable wrapper, and prove the downstream consumer smoke against kit plus bridge.

Keeping this issue open until #89 is merged/released and tummycrypt_scheduling_kit@0.7.6 is registered in tinyland-inc/bazel-registry.

[Jesssullivan]

2026-05-03 update from the package authority pass:

Current/latest release surfaces are aligned and independently proved now:

• scheduling-kit#89 merged at 6e90b733af5a4e8dd01d3f5eec747f0d764a08eb.
• GitHub release/tag v0.7.6 exists and targets that commit.
• Publish workflow 25265888924 passed Node 20/22 validation plus npm and GitHub Packages publish jobs.
• npm latest is @tummycrypt/scheduling-kit@0.7.6.
• tinyland-inc/bazel-registry#31 merged at 973414cee3a3384215aa6252513055fe781aa584, registering tummycrypt_scheduling_kit@0.7.6.
• Downstream Bzlmod consumer proof passed with no overrides, building both @tummycrypt_scheduling_kit//:pkg and @tummycrypt_scheduling_bridge//:pkg from the local registry.

I am leaving this open only if we still want explicit historical backfill/documentation for the older 0.7.1 / 0.7.2 release-surface gap. The current release/tag/npm/Bazel/registry authority path is now healthy.