Harden package devshell, remote cache, and publish provenance

[Jesssullivan]

Context

scheduling-kit is public and should be a clean reusable package consumer of the shared JS/Bazel workflow. Current package metadata is consistent at 0.7.2, and CI publishes Bazel output from ./bazel-bin/pkg, but the devshell and release hardening are not yet enterprise-grade.

Gaps

• flake.nix is present but no committed flake.lock was found in the audit clone.
• devshell does not clearly include Bazel/Bazelisk alongside the pinned Node/pnpm path.
• Bazel config is local-cache only; no documented remote-cache contract for contributors or CI canaries.
• workflows inherit secrets broadly and do not visibly declare least-privilege permissions, provenance, SBOM, or release concurrency.

Exit criteria

• committed lockfile or an explicit decision documenting why this public package does not lock the devshell
• documented nix develop validation command for contributors
• Bazel cache config documents local fallback and CI remote-cache behavior without private topology
• publish workflow uses explicit permissions, release concurrency, npm provenance where supported, and package/SBOM attestation or a documented deferral
• public docs remain free of private runner topology

[Jesssullivan]

2026-04-25 package lane update:

• scheduling-kit#76 merged the same publish credential forwarding fix used by bridge.
• PR CI proved the shared-runner lane after rerunning a transient Node 20 Bazel external fetch failure.
• The follow-up for shared Bazel external repo fetch hardening is now tracked in Harden js-bazel-package external repo fetches tinyland-inc/ci-templates#16.

This issue should stay focused on kit-local devshell/cache/provenance boundaries that are not solved by the shared workflow.

[Jesssullivan]

Opened #78 as a narrow repo-local provenance guard. It extends check-release-metadata so future changes must keep package/Bazel metadata aligned with the pinned shared js-bazel-package workflow, shared/same-runner mode, //:pkg, ./bazel-bin/pkg, and the GitHub Packages package name. Validation before PR: pnpm check:release-metadata and git diff --check.

[Jesssullivan]

Opened draft PR #82 to harden the workflow-authority guardrails for this lane: #82

Current local validation on the clean temp clone:

• pnpm check:release-metadata
• git diff --check
• nix develop -c actionlint

The PR adds explicit CI/publish permissions, workflow concurrency, npm provenance intent checks, and a public Bazel cache contract. Keeping it draft until remote GitHub checks actually report green, since runner availability may be stale today.

[Jesssullivan]

2026-05-02 follow-up: #89 now covers the concrete downstream Bazel consumer failure that remained after the workflow hardening PRs. Local proof for #89 includes bazel build //:pkg //:typecheck and a temp Bzlmod consumer building both @tummycrypt_scheduling_kit//:pkg and @tummycrypt_scheduling_bridge//:pkg with kit overridden to the fixed worktree.

This keeps the issue open for the release/registry closeout, but the devshell/cache/provenance thread now has a concrete consumer-build regression and fix path rather than just metadata hygiene.

[Jesssullivan]

2026-05-03 update:

The 0.7.6 lane proves the package build/publish portion of this issue is materially healthier:

• scheduling-kit#89 made //:pkg safe for downstream Bzlmod consumers by moving Svelte packaging into a writable Bazel temp project mirror.
• Main CI and release CI both passed Node 20/22 validation.
• Release v0.7.6 published npm and GitHub Packages successfully from the Bazel package artifact path.
• bazel-registry#31 registered tummycrypt_scheduling_kit@0.7.6 and registry validation passed.
• A no-override downstream Bzlmod consumer built @tummycrypt_scheduling_kit//:pkg and @tummycrypt_scheduling_bridge//:pkg from the registry.

Still not claiming this broader hardening issue complete: devshell/flake lock posture, contributor-facing remote-cache documentation, and SBOM/attestation decisions remain separate cleanup items.