steplock has never been released: no git tag, no GitHub Release, no crates.io publish

[tupe12334]

Summary

steplock has never actually been released: there is no git tag, no GitHub Release, and no steplock crate on crates.io. Every path documented in Installation.md for installing the CLI fails for a fresh consumer.

Reproduction

$ cargo install steplock
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate \`steplock\` does not exist"}]}

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty output)

$ gh api repos/polyhook/steplock/releases
[]

Observed vs expected

• Observed: cargo install steplock fails outright; https://github.com/polyhook/steplock/releases has no releases; crates.io has no steplock crate.
• Expected (per Installation.md, "Binary (recommended)" and "Package managers" sections): a downloadable release binary per platform, and cargo install steplock installing the published crate.

Root cause (as far as I can tell)

.github/workflows/release.yml is fully wired up (builds cross-platform binaries, creates a GitHub Release, then cargo publishs core/) and gated only on push: tags: v*. CHANGELOG.md still shows the 0.1.0 entry inside [Unreleased], core/Cargo.toml is at version = "0.1.0", and no v* tag has ever been pushed — so the release job has simply never run. This isn't a bug in the release workflow's logic itself; nobody has cut the first release yet.

Context

Found while dogfooding the latest published version of steplock as a downstream consumer for a nightly QA pass (also covering block-no-verify and @polyhook/sdk, both of which install and behave correctly at their latest published versions). Since there is no published artifact at all, the steplock-specific test scenarios (checklist gating, ack/advance persistence, branching flows) could not be run against a real install.

Suggested next step

Push a v0.1.0 tag (matching core/Cargo.toml) to trigger .github/workflows/release.yml, and confirm the CARGO_REGISTRY_TOKEN secret is configured so the publish job succeeds. This needs a maintainer to actually cut the tag/release (and confirm the crates.io token) — not something a source-only PR can fix, so I'm opening this as an issue only.

---

Filed by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" moadim routine.

[tupe12334]

Nightly dogfood re-confirmation (2026-07-24)

Still unreleased today, one day after this was filed — same result across all three checks:

$ cargo install steplock
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -H "User-Agent: nightly-dogfood-qa" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty)

$ gh api repos/polyhook/steplock/releases
[]

As before, this means the steplock-specific test scenarios (checklist gating, ack/advance persistence, branching flow.mmd) can't be exercised against a real published install this run either — recording that as skipped in tonight's summary rather than testing against repo source, consistent with this routine's "dogfood the published artifact" scope. Not opening a duplicate issue or PR; still needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is set for the publish job in .github/workflows/release.yml.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-07-25)

Still unreleased today — same result across all three checks, one day after the last re-confirmation:

$ cargo install steplock
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"detail\":\"We are unable to process your request at this time..."}]}
$ curl -s "https://crates.io/api/v1/crates?q=steplock"
{"crates":[]}

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty)

$ gh run list --repo polyhook/steplock --workflow release.yml --limit 20
# (empty — Release workflow has never run)

core/Cargo.toml is still version = "0.1.0", no v* tag exists, and the Release workflow (.github/workflows/release.yml) has zero runs in its history. Same conclusion as before: this isn't a code bug, it needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is set so the publish job succeeds.

Recording the steplock scenarios (checklist gating, ack/advance persistence, branching flow.mmd) as skipped in tonight's run for the same reason as yesterday — no published artifact exists to dogfood against. block-no-verify@1.3.0 and @polyhook/sdk@0.1.11 both installed from their registries and passed all scenarios tonight.

Not opening a duplicate issue or PR.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-07-26)

Still unreleased today — same result across all checks, two days after the last re-confirmation:

$ cargo install steplock
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -A "steplock-dogfood-test" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ curl -s -A "steplock-dogfood-test" https://index.crates.io/st/ep/steplock
<Error><Code>NoSuchKey</Code>...</Error>

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty)

$ gh api repos/polyhook/steplock/releases
[]

$ gh run list --repo polyhook/steplock --workflow release.yml --limit 20
# (empty — Release workflow has never run)

core/Cargo.toml is still version = "0.1.0", no v* tag exists, and .github/workflows/release.yml has zero runs. Same conclusion as the prior three days: not a code bug, needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is configured so the publish job succeeds.

As a result, the steplock-specific scenarios (checklist gating via .steplock/checklists/<name>/config.toml + flow.mmd, ack/advance persistence one-item-per-invocation, and branching flow selection) were read through in source/docs (Installation.md, README.md, examples/git-push-quality-gate/) to confirm the documented contract is coherent, but could not be exercised against a real published install this run — recording as skipped in tonight's summary, consistent with this routine's "dogfood the published artifact only" scope. Not opening a duplicate issue or PR.

@tupe12334 — this is now day 4 with the same blocker; flagging in case the tag/publish step needs a nudge.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-07-27)

Still unreleased today — day 5 with the same blocker:

$ cargo install steplock
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -A "moadim-nightly-dogfood/1.0" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ gh release list --repo polyhook/steplock
# (empty)

$ gh api repos/polyhook/steplock/tags
[]

$ gh run list --repo polyhook/steplock --workflow release.yml --limit 20
# (empty — Release workflow has still never run)

core/Cargo.toml is still version = "0.1.0", no v* tag exists. Same conclusion as prior days: needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is configured for .github/workflows/release.yml's publish job.

New finding this run: while digging into why a release might not have been cut yet, I found main's CI (ci.yml) has been red — unrelated to the release gate itself (release.yml only triggers on tag push), but worth knowing about since a maintainer cutting the first tag will land on a repo with failing CI. Opened #188 with the two root causes (a mistyped MSRV toolchain pin, and invalid upload-artifact inputs on the coverage job) — a fix is ready but pushing it was blocked by this bot's OAuth token intentionally lacking workflow scope, so the diff is posted on #188 for a maintainer to apply.

steplock-specific scenarios (checklist gating, ack/advance persistence, branching flow.mmd) remain untestable against a real published install and are recorded as skipped in tonight's summary. block-no-verify@1.3.0 and @polyhook/sdk@0.1.11 both installed from their registries and passed all scenarios tonight.

Not opening a duplicate issue for the release-blocker itself.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-07-28)

Still unreleased today — day 6 with the same blocker, same result across all checks:

$ cargo install steplock
    Updating crates.io index
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -A "moadim-nightly-dogfood/1.0" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty)

$ gh release list --repo polyhook/steplock
# (empty)

$ gh run list --repo polyhook/steplock --workflow release.yml --limit 10
# (empty — Release workflow has still never run)

core/Cargo.toml is still version = "0.1.0", no v* tag exists.

Good news since the last check-in: the CI-red blocker flagged on 2026-07-27 (#188) is now fixed — PR #189 merged the toolchain-pin and coverage-artifact-upload fix, and CI on main is green as of 2026-07-27T01:21:14Z. So there's no longer any reason a first tag push would land on a broken main.

Same conclusion as the prior five days: not a code bug, just needs a maintainer to push a v0.1.0 tag (matching core/Cargo.toml) and confirm CARGO_REGISTRY_TOKEN is configured for .github/workflows/release.yml's publish job.

steplock-specific scenarios (checklist gating via .steplock/checklists/<name>/config.toml + flow.mmd, ack/advance persistence one-item-per-invocation, branching flow selection) remain untestable against a real published install and are recorded as skipped in tonight's summary, consistent with this routine's "dogfood the published artifact only" scope. block-no-verify@1.3.0 and @polyhook/sdk@0.1.11/PyPI polyhook@0.1.11 were all installed from their registries and tested this run.

Not opening a duplicate issue or PR. @tupe12334 — day 6, CI is now clear so this is just the tag push away from being resolved whenever you get a chance.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-07-29)

Still unreleased today — day 7 with the same blocker, same result across all checks:

$ cargo install steplock
    Updating crates.io index
error: could not find `steplock` in registry `crates-io` with version `*`

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty)

$ gh release list --repo polyhook/steplock
# (empty)

$ gh api repos/polyhook/steplock/tags
[]

$ gh run list --repo polyhook/steplock --workflow release.yml --limit 10
# (empty — Release workflow has still never run)

core/Cargo.toml is still version = "0.1.0", no v* tag exists. Same conclusion as the prior six days: not a code bug, just needs a maintainer to push a v0.1.0 tag (matching core/Cargo.toml) and confirm CARGO_REGISTRY_TOKEN is configured for .github/workflows/release.yml's publish job — CI on main has been green since 2026-07-27 (#189 merged), so there's no blocker left on that front either.

steplock-specific scenarios for tonight's run (linear checklist ack/advance persistence with a hand-authored 2-3 state flow.mmd, and a branching flow.mmd with two outgoing transitions from one state) remain untestable against a real published install and are recorded as skipped in tonight's summary, consistent with this routine's "dogfood the published artifact only" scope — the task explicitly requires installing via cargo install steplock (not building from the cloned repo source) for the actual test.

Not opening a duplicate issue or PR. @tupe12334 — day 7, still just the tag push away from being resolved.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-07-30)

Still unreleased today — day 8 with the same blocker:

$ cargo install steplock
    Updating crates.io index
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -H "User-Agent: nightly-dogfood-agent" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ gh api repos/polyhook/steplock/tags
[]

$ gh release list --repo polyhook/steplock
# (empty)

core/Cargo.toml is still version = "0.1.0", no v* tag exists. CI on main remains green (last push 2026-07-27T01:21:14Z). Same conclusion as the prior seven days: not a code bug, just needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is configured for .github/workflows/release.yml's publish job.

steplock-specific scenarios (checklist gating, ack/advance persistence, branching flow.mmd) remain untestable against a real published install and are recorded as skipped in tonight's summary. block-no-verify@1.3.0 and @polyhook/sdk@0.1.11 were installed from their registries and tested this run (see tupe12334/block-no-verify#68 for one still-open, already-tracked gap on the block-no-verify side; @polyhook/sdk passed all scenarios).

Not opening a duplicate issue or PR. Day 8, still just the tag push away from being resolved.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-07-31)

Still unreleased today — day 9 with the same blocker, same result across all checks:

$ cargo install steplock
    Updating crates.io index
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s "https://crates.io/api/v1/crates?q=steplock" -H "User-Agent: dogfood-agent (contact: test)"
{"crates":[],"meta":{"total":0,"next_page":null,"prev_page":null}}

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty)

$ gh release list --repo polyhook/steplock
# (empty)

core/Cargo.toml is still version = "0.1.0", CHANGELOG.md's [Unreleased] section keeps growing (now includes steplock init, session:stop cleanup, allow_preview_request, command_words CEL variable, reset = "always", Windows release target, audit log, etc.), and cargo build --manifest-path core/Cargo.toml from source succeeds cleanly — the project looks release-ready, it just hasn't been tagged. Skipping the steplock dogfood checklist scenarios again this run since there is nothing installable to test against; no new issue/PR filed (this one already covers it).

---

Filed by the automated Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock) routine.

[tupe12334]

Nightly dogfood re-confirmation (2026-08-01)

Still unreleased today — day 10 with the same blocker, same result across all checks:

$ cargo install steplock
    Updating crates.io index
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -A "moadim-nightly-dogfood/1.0 (contact: ofek.gabay.he@gmail.com)" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate \`steplock\` does not exist"}]}

$ gh api repos/polyhook/steplock/tags
[]

$ gh release list --repo polyhook/steplock
# (empty)

core/Cargo.toml is still version = "0.1.0", no v* tag exists. Not a code bug — same conclusion as the prior nine days: needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is configured for .github/workflows/release.yml's publish job.

steplock-specific scenarios (checklist gating, ack/advance persistence, branching flow.mmd) remain untestable against a real published install and are recorded as skipped in tonight's summary. block-no-verify@1.3.0 and @polyhook/sdk@0.1.11 were installed from their registries and fully tested this run — @polyhook/sdk passed all scenarios (npm, Rust polyhook-core, Python polyhook); block-no-verify passed every scenario in tonight's sweep except the already-tracked unpublished-fix gap (see tupe12334/block-no-verify#68).

Not opening a duplicate issue or PR. Day 10, still just the tag push away from being resolved.

Filed automatically by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" moadim routine.

[tupe12334]

Nightly dogfood re-confirmation (2026-08-05)

Still unreleased today — same result across all checks, four days after the last re-confirmation:

$ cargo install steplock
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -H "User-Agent: nightly-qa-agent" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty — still no v* tag)

$ gh run list --repo polyhook/steplock --workflow release.yml --limit 5
# (empty — Release workflow has still never run)

Same conclusion as prior nights: not a code bug — needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is set for the publish job in .github/workflows/release.yml. Recording the steplock scenarios (checklist gating, ack/advance persistence, branching flow.mmd) as skipped tonight since there is no published artifact to dogfood.

For the record, the other two libraries passed tonight: block-no-verify@1.3.0 (all block/allow scenarios incl. no-envelope shape) and @polyhook/sdk@0.1.11 (TS, Python 0.1.11 via uv/py3.12, and polyhook-core 0.1.11 Rust smoke test).

Not opening a duplicate issue or PR.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-08-06)

Still unreleased today — same result across all checks, one day after the last re-confirmation:

$ cargo install steplock
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -A "moadim-nightly-qa" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty)

$ gh run list --repo polyhook/steplock --workflow release.yml --limit 5
# (empty — Release workflow has never run)

Recording the steplock scenarios (checklist gating, ack/advance persistence, branching flow.mmd) as skipped again tonight — no published artifact exists to dogfood against. Tonight's other results: block-no-verify@1.3.0 and @polyhook/sdk@0.1.11 (npm), polyhook-core@0.1.11 (crates.io), and polyhook@0.1.11 (PyPI) all installed from their registries and passed all scenarios.

Still needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is set for the publish job. Not opening a duplicate issue or PR.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-08-07)

Still unreleased tonight — same state as prior re-confirmations:

$ cargo install steplock
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -A "moadim-nightly-qa" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ gh release list -R polyhook/steplock   # empty
$ gh api repos/polyhook/steplock/tags    # empty

core/Cargo.toml still reads version = "0.1.0" with everything under [Unreleased] in the changelog. steplock scenarios recorded as skipped again tonight (no published artifact to dogfood). The other two libraries installed from their registries and passed all scenarios tonight: block-no-verify@1.3.0 and @polyhook/sdk/polyhook 0.1.11 (npm, crates.io, PyPI).

Still needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN so the release.yml publish job runs.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.

[tupe12334]

Nightly dogfood re-confirmation (2026-08-09)

Still unreleased today — same result across all checks, two days after the last re-confirmation:

$ cargo install steplock
    Updating crates.io index
error: could not find `steplock` in registry `crates-io` with version `*`

$ curl -s -A "moadim-nightly-dogfood/1.0 (contact: ofek.gabay.he@gmail.com)" https://crates.io/api/v1/crates/steplock
{"errors":[{"detail":"crate `steplock` does not exist"}]}

$ git ls-remote --tags https://github.com/polyhook/steplock.git
# (empty)

$ gh release list --repo polyhook/steplock
# (empty)

$ gh api repos/polyhook/steplock/tags
[]

$ gh run list --repo polyhook/steplock --workflow release.yml --limit 10
# (empty — Release workflow has still never run)

core/Cargo.toml is still version = "0.1.0", no v* tag exists, CI on main remains green (last runs 2026-08-02/2026-08-03). Same conclusion as the prior re-confirmations: not a code bug, just needs a maintainer to push a v0.1.0 tag and confirm CARGO_REGISTRY_TOKEN is configured for .github/workflows/release.yml's publish job.

Per this run's brief, I read the linear- and branching-checklist shape against examples/git-push-quality-gate/ and the schema (schemas/checklist-config.schema.json) to confirm the documented contract (config.toml + flow.mmd, one item acknowledged per hook invocation via the generated ack.sh, branching via multiple outgoing transitions) is internally coherent, but as before these scenarios remain untestable against a real published install and are recorded as skipped in tonight's summary — consistent with this routine's "dogfood the published artifact only" scope.

Not opening a duplicate issue or PR.

---

This comment was posted by the "Nightly lib dogfood → issue + PR (polyhook, block-no-verify, steplock)" routine of moadim.