docs: badge what this repository actually guarantees

[open-coder-ai]

What

Every sibling repository carries a row of trust signals; this one carried none. A visitor had no at-a-glance answer to is this maintained, what may I do with it, and where do changes go.

Three badges, each backed by something real in this repository:

Badge	Backed by
Generated-only	.github/workflows/generated-only.yml
License Apache 2.0	LICENSE
Contribute → chock-catalog	.github/workflows/close-prs.yml

Generated-only leads deliberately. As its own workflow comment says, that check "is not a lint, it is the security argument": it regenerates from the pinned catalog sources and fails on any difference, so what a user installs is exactly what the catalog published. For a repository asking people to approve a hook trust review before its guards can block, the check backing that guarantee should be the first thing on the page.

What is deliberately not here

No "PRs welcome" badge, though every sibling carries one. This repository closes hand-written pull requests by design — review belongs where the source is. A "PRs welcome" badge would walk people into a pull request that gets closed unread, which is worse than no badge at all. The third badge states the true thing instead.

No OpenSSF Scorecard badge. There is no scorecard workflow here, and a badge for a check that does not run is exactly the kind of claim this project exists not to make.

Note on close-prs.yml

This PR is on a branch in this repository, not a fork, so the redirect workflow's fork-only condition leaves it alone — matching its own comment that "a branch in this repository is the maintainer's own infrastructure work".

Status

main was republished at framework v0.7.0 (1376438), and this branch has been updated onto it, so the verify failure noted in the comment below is resolved.

Same pass applied across the org: chock-claude-plugins, chock-cursor-plugins, chock-copilot-plugins, chock-quickstart, chock-example, chock-threat-intel, agentseam and chock-catalog.

[open-coder-ai]

Generated-only is red, and it is not this PR

This PR changes one file, README.md, adding four lines. The diff the failing job printed is the guard runtime, not that.

Root cause: chock 0.7.0. The workflow checks out open-coder-ai/chock at its current main and regenerates with it, while this repository's committed tree was published by framework v0.6.0. The five-axis migration landed in chock today, so regenerating now produces a different runtime than the one committed here and git diff --exit-code fails. The same check was green on main yesterday under 0.6.0, and fails on main today with no PR involved.

There is no fix to push from inside this PR. What clears it is republishing this distribution against chock 0.7.0 — tracked in open-coder-ai/chock#79 with the other two plugin repositories. No re-run spent: this is deterministic, not a flake.

On the "no one hand-edits this repo" question

Worth stating, because I got it wrong first and then checked: README.md is the one file deliberately exempt from generation here, so this change will not be regenerated away. From chock/src/chock/plugin/marketplace.py, beside CATALOG_PAGE = "PLUGINS.md":

It is a file of its own rather than a managed region inside README.md. The repository's rules put README.md off limits to tooling, and honouring that boundary costs nothing here.

Confirmed three ways: the generator never writes README.md, chock-market.lock does not cover it, and PLUGINS.md exists precisely so the README can stay hand-maintained. Everything else here is compiled output and should never be hand-edited — that part is exactly right.

---

Generated by Claude Code

[open-coder-ai]

verify is failing, and it is not this diff. Recording why, since it will stay red until something outside this pull request lands.

What fails: the generated-only check regenerates the whole tree from chock-catalog@main and diffs it against what is committed here. The published tree was built with framework v0.5.0; the catalog now pins v0.7.0. This pull request adds four lines to README.md and touches nothing else, and README.md is not part of what verify regenerates.

Why it cannot be fixed here: the check compares the entire generated tree, so the only thing that clears it is republishing that tree at v0.7.0 — publish.yml with framework_ref: v0.7.0. That is a push to this repository's main, not a change to this branch. Committing regenerated content onto this branch would be hand-editing generated files, which is the exact thing the check exists to prevent.

Where that stands: the dry run at catalog_ref: main, framework_ref: v0.7.0 has been executed on this repository and succeeded — catalog checks, evals, and package validation all passed. The real publish is held pending the maintainer's go-ahead, because it pushes to a repository people install from.

No re-run requested: this is a deterministic version gap, not a flake, and a second run would fail identically. This pull request goes green on its own once the republish lands.

---

Generated by Claude Code